B│Ωdy oprogramowania wystΩpuj▒ nawet w najlepiej sprawdzonych programach. Wed│ug bada± IBM najczΩ╢ciej wystΩpuj▒ b│Ωdy, kt≤re mog▒ wywo│aµ awariΩ systemu raz na 5000 lat. Usuwanie takich b│Ωd≤w jest syzyfow▒ prac▒. WiΩkszo╢µ z nas do╢wiadczy│a problem≤w zwi▒zanych z wadliwym dzia│aniem oprogramowania, takich jak zawieszenie siΩ systemu operacyjnego. Defekty oprogramowania wywo│a│y na przyk│ad seriΩ przerw w pracy telefon≤w na znacznych obszarach Stan≤w Zjednoczonych. Wadliwy program m≤g│ uniemo┐liwiµ rakietom Patriot trafienie irackiej rakiety Scud, kt≤ra zabi│a 28 ┐o│nierzy ameryka±skich podczas wojny w Zatoce Perskiej.

Podstaw▒ problemu jest z│o┐ono╢µ program≤w, kt≤ra zwiΩksza prawdopodobie±stwo zaistnienia b│Ωd≤w i pojawienia siΩ ich w ostatecznej wersji. W tradycyjnym systemie produkcji dokona│ siΩ znaczny postΩp w zrozumieniu i kontroli defekt≤w. Chocia┐ b│Ωdy projektowe wystΩpuj▒ czasem w produktach nie zawieraj▒cych komputer≤w, jednak wzglΩdna prostota tych wyrob≤w zmniejsza znaczenie ich niezawodno╢ci w por≤wnaniu z oprogramowaniem.

Osi▒gniΩcie idealnego oprogramowania pozostaje tylko marzeniem. Pomimo rygorystycznego i systematycznego testowania wiΩkszo╢µ du┐ych program≤w zawiera nie usuniΩte defekty od chwili, w kt≤rej zaczynamy je stosowaµ. Przyczyn▒ tego jest z│o┐ono╢µ ich kod≤w ╝r≤d│owych. Program zbudowany z zaledwie kilku setek linijek mo┐e zawieraµ dziesi▒tki rozkaz≤w umo┐liwiaj▒cych wyst▒pienie tysiΩcy r≤┐nych sposob≤w wykonania. Programy kontroluj▒ce krytyczne zastosowania zawieraj▒ od dziesi▒tk≤w do milion≤w linii kodu ╝r≤d│owego. Program taki mo┐e podj▒µ b│Ωdn▒ decyzjΩ, gdy┐ przypadkowy uk│ad sygna│≤w, kt≤ry do niej doprowadzi, nie zosta│ przetestowany w okresie usuwania b│Ωd≤w. Taki uk│ad sygna│≤w wej╢ciowych mo┐e byµ nawet ╝le zrozumiany lub nieprzewidziany. Programista m≤g│ prawid│owo zaprojektowaµ z│▒ reakcjΩ lub w og≤le nie przewiedzieµ wyst▒pienia danej sytuacji. Ten typ defektu programu jest najtrudniejszy do ca│kowitego wyeliminowania.

Niepowodzenia rakiet Patriot przy przechwytywaniu irackich rakiet Scud przypisano efektom nagromadzenia siΩ niedok│adno╢ci w pracy wewnΩtrznego zegara komputera. Przedtem komputer dzia│a│ zgodnie z przyjΩtymi za│o┐eniami -przewidywano, ┐e bΩdzie on wy│▒czany i w│▒czany dostatecznie czΩsto, by kumulacja b│Ωdu nie by│a nigdy niebezpieczna. Poniewa┐ zosta│ zastosowany w spos≤b pierwotnie nie przewidywany, niewielka niedok│adno╢µ sta│a siΩ powa┐nym problemem.

Jeden b│Ωdny bit w programie kontroluj▒cym lot rakiety Atlas, kt≤ra wynios│a w przestrze± kosmiczn▒ pierwsz▒ ameryka±sk▒ sondΩ miΩdzyplanetarn▒ Mariner 1, spowodowa│ jej zej╢cie z w│a╢ciwego kursu. W konsekwencji zar≤wno rakieta, jak i sonda uleg│y zniszczeniu wkr≤tce po starcie.

Poza mimowolnie wprowadzonymi do programu b│Ωdami, zawiera on r≤┐nego rodzaju uproszenia bΩd▒ce skutkiem kompromisu, kt≤re mog▒ wywo│aµ niemo┐liwe do akceptacji zachowanie siΩ systemu.

Przyjmuj▒c, ┐e istnienie idealnego oprogramowania jest praktycznie niemo┐liwe, mo┐emy zapytaµ jak stwierdziµ, czy dany program jest ju┐ dostatecznie niezawodny? Pierwszym kryterium s▒ wymogi bezpiecze±stwa, kt≤re zale┐▒ od przeznaczenia danego programu. Na przyk│ad w USA wymaga siΩ, aby nowy system kontroli lot≤w nie ulega│ awariom d│u┐szym ni┐ 3 sekundy w ci▒gu roku. W cywilnych liniach lotniczych prawdopodobie±stwo pewnych niebezpiecznych awarii nie mo┐e przekraczaµ jednej miliardowej w ci▒gu jednej godziny. Podobnie w planach samolot≤w w pe│ni sterowanych przez komputery, takich jak Airbus A320 czy Boeing 777, mo┐liwo╢µ katastrofy spowodowanej b│Ωdem w oprogramowaniu musi byµ por≤wnywana z mo┐liwo╢ci▒ przeciwdzia│ania nieszczΩ╢liwemu wypadkowi wynikaj▒cemu z b│Ωdu pilota czy awarii kt≤rego╢ z urz▒dze±.

Niestety, takie podej╢cie mo┐na stosowaµ jedynie przy umiarkowanych wymaganiach niezawodno╢ci systemu, zak│adaj▒cych na przyk│ad jedn▒ awariΩ na kilka lat pracy. Przy ostrych kryteriach niezawodno╢ci zastosowania osi▒gniΩcie odpowiedniego poziomu ufno╢ci, w kt≤rym mo┐liwo╢µ awarii nie mo┐e przekroczyµ jednej miliardowej na godzinΩ, wymaga│oby badania programu przez miliard≤w godzin, czyli setki tysiΩcy lat. Jest to oczywi╢cie niemo┐liwe. Przetestowanie program≤w w realnym czasie oznacza zmniejszenie poziomu bezpiecze±stwa o wiele rzΩd≤w wielko╢ci w stosunku do potrzeb.

Zagadnienie to nazywa siΩ prawem malej▒cych efekt≤w. Je╢li usuwamy b│Ωdy przez d│u┐szy czas, w≤wczas znajdujemy coraz mniej istotne b│Ωdy, kt≤rych eliminacja nie ma praktycznie ┐adnego istotnego wp│ywu na og≤ln▒ niezawodno╢µ systemu.

Je┐eli kto╢ przekonuje nas o wyj▒tkowej niezawodno╢ci i bezpiecze±stwie pojedynczego programu, mo┐emy mu zarzuciµ po prostu brak dostatecznej wiedzy. W przypadku z│o┐onych program≤w przykr▒ prawd▒ jest fakt ograniczonego zaufania, na kt≤re mo┐na sobie pozwoliµ. Sama obserwacja programu w trakcie jego dzia│ania nie daje gwarancji jego zachowania siΩ za 100 000 lat.

Powszechnie dzi╢ stosowan▒ metod▒ prowadz▒c▒ do wysokiej niezawodno╢ci (na przyk│ad w kontroli lot≤w i ruchu poci▒g≤w) jest tolerancja b│Ωd≤w lub metoda zabezpieczaj▒cej redundancji, czyli nadmiaru. Typowym sposobem stosowania redundancji jest posiadanie r≤┐nych wersji oprogramowania opracowanych przez r≤┐ne grupy programist≤w. Mo┐na przypuszczaµ, ┐e w poszczeg≤lnych wersjach programu pojawi▒ siΩ r≤┐ne b│Ωdy. Ka┐da z wersji programu podaje w│asn▒ 'opiniΩ' o prawid│owo╢ci wyniku. NastΩpnie urz▒dzenie rozstrzygaj▒ce podejmuje ostateczn▒ decyzjΩ - prawid│ow▒, je╢li przewa┐aj▒ wyniki poprawne.

Istnieje wiele dowod≤w, ┐e taki system prowadzi do wysokiej niezawodno╢ci, choµ kosztuje dro┐ej. Nie mo┐na jednak wykluczyµ, ┐e r≤┐ne grupy programist≤w pope│ni▒ takie same b│Ωdy (na przyk│ad z powodu wsp≤lnej mentalno╢ci kulturowej) lub b│Ωdy r≤┐ne, ale prowadz▒ce do identycznych awarii. Urz▒dzenie rozstrzygaj▒ce w takim wypadku wybierze fa│szywe rozwi▒zanie.

WiΩc nie narzekaj u┐ytkowniku, kiedy aplikacja kt≤rej u┐ywasz nagle äpadnieö, zastan≤w siΩ nad poziomem komplikacji takiego programu. Czym bardziej skomplikowany system tym wiΩksze szanse na wystΩpowanie awarii (dotyczy to nie tylko program≤w ale i urz▒dze± z kt≤rych korzystamy).

 

Autor:
Grzegorz Ga│Ωzowski
gsgalezowski@poczta.onet.pl